Аналитический мир огромен и неоднороден. Нас разделяют расстояния, разница во времени, в культуре, языковый барьер. Но, ничто не разделяет нас так, как приверженность к различным подходам. Главный водораздел проходит между двумя, порой, непримиримыми лагерями: приверженцами классического подхода и приверженцами идеологии Agile. Кто же из них прав? Под чьи знамена встать, что бы не ошибиться в жизненном выборе? А нужно ли вообще выбирать? Данный доклад - это результат долгого спора с поклонниками и оппонентами этих двух полярных подходов. В докладе будет рассказано, что существуют вполне понятные и формализованные признаки проекта, анализ которых и позволит нам выбрать наилучший подход для каждого отдельного проекта.
мастер класс
Кумсков ЛАФ-2014
Системный подход: Модель Предметной области, модель Бизнес-системы и модель Информационной системы – строим вместе.
На мастер классе будет разобрана три примера (за 90 минут) - один пример показывается по шагам на слайдах. Строятся три модели: модель ИС (прототип модели сценариев использования), модель бизнеса (прототип модели бизнес сценариев использования) и модель предметной области. Второй и третьи примеры слушатели строят в группах по 3-5 человек и публикуют на листах флип-чарта (развешанных на стенке), затем проводится «разбор полета». Мастер класс показывает внутреннюю взаимосвязи и синергию трех представлений задачи – трех моделей.
При создании программного обеспечения нередко возникает непонимание между различными группами заинтересованных лиц (заказчиками, аналитиками, разработчиками и другими). Это неизбежно вызывает расхождение между пожеланиями заказчика и готовым продуктом. Особенно много недоразумений обычно связано с реализацией, т.к. для участников проекта, не являющихся программистами, код представляет собой ‘чёрный ящик’ и почти не поддаётся контролю.
Что системному аналитику делать с чёрным ящиком? В докладе рассматриваются некоторые приёмы, способствующие организации эффективного взаимодействия с разработчиками.
Нет предела совершенству! И как только более-менее стабилизируется процесс разработки требований, начинаются вопросы - а что же делать, если требования меняются? Такой вопрос возникал и у меня на разных проектах. В ходе размышлений и опытов родился некоторый подход, которым хотелось бы поделиться и развить с учетом мнения коллег в ходе этого доклада.
Вопросы:
1) постановка задачи: какие же проблемы мы хотим решить?
2) варианты реализации управления изменениями: в рамках одной версии, в рамках нескольких версий
3) цикл жизни артефактов проекта - а за всеми ли изменениями нужно следить?
В целом доклад базируется на моем вебинаре https://www.webursitet.ru/article/versionirovanie-trebovanii--zapis-vebinara.html , поэтому буду рада вопросам, которые покажут, в какую сторону надо развить тему.
Ну вот кто с этим не знаком? Нужно там, ну не знаю, сервис на мобилу подключить. Лезешь на портал, а там просят указать
«Ваш звонок очень важен для нас, оператор освободится через 10 минут, очередь — 20 входящих»,
«Ой, у нас нет вашего письма»,
«Нет, ну вы нам не писали, нет заявки»,
«Я не могу Вам ответить, сейчас соединю со специалистом»,
«Кто, я в этом специалист? чо они там несут??? звоните им снова и пусть Вас пошлют
И вот если отбросить уголовно наказуемые желания по отношению к тем, кто все это придумал, остается одно: глядя этим людям в глаза спросить — ну как так вышло, что вышло ну никак?
Уверены, что это не со зла. И задумка то была благородная, и на бумаге все срасталось. Но почему в
Не, ну вы конечно скажете — тут UX нужен. А факт ли? Положим, есть инструменты, позволяющие спроектировать удобную для клиента услугу. Один из наиболее эффективных — это Customer Journey Map (CJM).
Но хватит ли UX дизайнера для проектирования того, что на самом деле представляет собой замес из
Где золотая середина? Как сделать так, чтобы все были счастливы?
Вот об этом предлагаем и поговорить.
Целью воркшопа является ознакомление слушателей с теоретическими основами CJM и получение практических навыков ее разработки.
В теоретической части будет раскрыта общая идея CJM, показаны подходы к ее разработке, даны рекомендации по формату представления CJM. Кроме того, будет уделено внимание зависимостям между
В практической части участникам воркшопа будут предложены задания по проектированию новых сервисов или оптимизации существующих. Результаты выполнения практических заданий будут вынесены на коллективное обсуждение.
В результате участия в воркшопе участники получат в свою копилку ещё один инструмент, который поможет более системно подходить к локальным улучшениям и видеть не только разрабатываемое ПО, но и услугу (а то и весь бизнес) вокруг этого ПО.
1. Все лгут
2. Где брать информацию?
3. Чему доверять?
4. Что делать с недостоверными данными?
5. Когда нужно, чтобы информация достоверной?
Основные тезисы доклада: